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(57) An international cryptography framework (IGF) 
connprises a set of service elements which allow appti- 
cations to exercise cryptographic functions under the 
control of a policy. The four core elements of the ICF 
architecture, Le. the host system (16), cryptographic 
unit (1 4). policy activation token (37), and network secu- 
rity server (18), comprise an infrastructure that provides 
cryptographic services to applications. Applications that 
request cryptographk; services from various service 
elements within the ICF are identified through a certifi- 
cate (36) to protect against misuse of a granted level of 

FIG. 3 r 



cryptograpliy. The host system comprises a set of sys- 
tem programs and services which provide the applica- 
tion with an execution environment. The host system 
provides services to the application in the form of pro- 
gramming interfaces to access the functions offered by 
the cryptographic unit. The host system also provides 
support for the cryptographic unit in l3uikJing trust rela- 
tionships to the host system elements, such as the ayp- 
tographic programming interfaces, operating systenr^ 
drivers, and memory management subsystems. 
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Description 

[0001] The invention relates to cryptographic apparatus and ayptography. More particularly, the invention relates to 
host system elements for an international cryptography framework. 

[0002] Customers of large computer systems are typically multinational corporations that want to purchase enterprise 
wide computer t>ased solutions. The distributed nature of such organizations requires them to use putrfic international 
communications services to transport data throughout tiieir organization. Naturally, they are concerned about the secu- 
rity of their communications and seek to use modern er>d-to-end cryptographic facilities to assure privacy and data 

integrity. , i ■ • 

[0003] The use of cryptography in communications is governed by national policy and unfortunately, national policies 
differ with respect to such i^e. Each national policy is developed independently, generally with a more national enrpha- 
sis rather than international considerations. There are standards groups tiiat are seeking to develop a common crypto- 
graphic algorithm suitable for international cryptography. However, tiie issue of international cryptographic standards is 
not a technical problem, but rather it is a political issue that has national sovereignty at its heart As such, it is not real- 
istic to expect tiie different national cryptography policies to come into alignment by a technical standardization process. 
[0004] The issue of national interests in cryptography is a particular concern of companies that manufacture open- 
standards-based information technology products for a worldwide market. The market expects these products to be 
secure. Yet. more and more consumers of these products are tiiemselves multinational and look to the manufacturers 
to help them resolve the international cryptography issues inhibiting their worldwide information technoiogy develop- 
ment. The persistence of unresolved differences and export restrictions in national cryptography policies has an 
adveree inpaet on international market growtii for secure open computing products. Thus, rt would ba helpful to provide 
an international framework that provides global information technology products featuring common secuity elements, 
while respecting the independent development of national cryptography policies. 

[0005] Nations have reasor^s for adopting policies that govern cryptography. Often these reasons ^^ve to do with law 
25 enforcement and national security issues. Witiiin each country there can be debates between the government and the • 
people as to rigmness arrcl acceptability of these policies. Ratiier than engage in theso debates or try to forecast 
their outcome, it is more practical to accept the sovereign right of each nat^ofi to establish an independent poiicy gov- 
erning cryptography in communication. 

[0006] Policies governinQ naiior^al cryptograph^' not only express the m\\ of the people and govarnme^Tt. but also 
entirace certain technologies that fadlitate cryptography. Technology choice is certainly one area where standardiza- 
tion can play a role. However, as indicated earlier tfiis is not solely a technical problem, such that seiedion off comnron 
cryptographic technologies alone can not resolve the national policy differences. Consequentiy. it would be useful to 
provide a common, accepted cryptography framework, wherein independem technology and policy choices can be 
made in a way that still enables international cryptographic communicattons consistent with tiiese poliaes. 
[0007] A four-part technology framework that supports international cryptography, which includes a national flag card, 
a cryptographic unit, a host system, and a network security server is disclosed by K. Klemba, R. MerckRng, Internatwnal 
Cryptography Framework, in US. patent no. 5.651 ,068, issued 22 July 19S7. Three of tiiese four service elements have 
a fundamentally hierarchical relationship. The National Flag Card (NFC) is installed into the Cryptographic Unit (CU) 
which, in turn, is installed into a Host Sy^em (HS). Cryptographic functions on the Host System cannot be executed 
without a Crypto^aphic Unit, which itself requires the presence of a valid National Flag Card before it's services are 
available. The fourth service element a Network Security Server (NSS). can provide a range of different security serv- 
ices including verificatton of the other three service elements. 

[0008] The framework supports the design, inrplementation, and operational eiements of any and all national policies, 
while unifying the design, devetopment, and operation of independent national security policies. The framework thus 

45 gives standard form to the service dements of netkmal security policies, where such service elements include such 
things as hardware form fectors. communication protocols, and on-line and oH-line data definitions. 
[0009] Critical to the iirplementation of the framework is the provision of a fundannental technology that allows the 
production of the various service elements. While various implementations of tiie service elements are within the skill 
of those versed in the re!«/ant art. tiiere exists a need for specific improvements to the state of the art if the full potential 

50 of the framework is to be realized. ^ ^ • 

[001 0] In particular, it woukl be desirable for the host system elements of such framework to provde support services 
to applications policies, and Operating Systems that run within such framework, e.g. support for applications would 
include an application programming interface (API) to allow access to the cryptogtaphic sen/ices in the cryptographic 
unit. Further, it would be desirable for such host system elements to provide support for the cryptographic unit in build- 

55 ing trust relationships between the host system elements and the cryptographic unit. 

[0011] An interrwtional cryptography framework (ICF) is provided tiiat allows manufacturers to comply witii varying 
national laws governing the distribution of cryptographic capabilities. In particular, such a framework makes it possible 
to ship worldwide cryptographic capabilities in all types of information processing devices {e.g. printers, palm-tops); The 
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ICF comprises a set of service elements which allow applications to exercise cryptographic functions under the control 
of a policy. The four core elements of the ICF architecture, i.e. the host system, cryptographic unit, policy card, and net- 
v.'ork security server, comprise an infrastructure that provides cryptographic sen/ices to applications. Applications that 
request cryptographic services from various service elements within the ICF are identified through a certificate to pro- 
5 tect against misuse of a granted level of cryptography. The policy nriay take into consideration attributes contained in the 
/application Certificate. 

[001 2] The host system comprises a set of system programs and services which provide the application with an exe- 
cution environment. The host system's role within the IGF is twofold. First, the host system provides services to the 
application in the form of programming interfaces to access the functions offered by the cryptographic unit. Second, the 
10 host system provides support for the cryptographic unit in building trust relationships to the host system elements, such 
as the cryptographic programming interfaces, operating systems drivers, and memory management subsystems. 

Fig; 1 is a t>lock diagram of an ir.ternationai cryptography framework, including a National Rag Card (also referred 
to herein as a policy activation token), a ayptographic unit, a host system, and a network security server according 
15 to the invention; 

Fig. 2 is a block diagram showing a software architecture overview according to the invention; 
Fig. 3 is a block diagram showing ICF management elements according to the invention; 

20 

Fig. 4 is a l>lock diagram showing a trust relation between an application arxi a cryptographic unit according to the 
invention; 

Fig. 5 is a block diagram that shows an application installation and update according to the invention; 

Fig. 6 is a block diagram showing the compound representation of the process of transforming a Base B with a 
transform T as approved by the signing Authority according to the invention; 

Fig, 7 is a block diagram that shows downloading and execution of an applet according to the invention; 
Fig. 8 is a block diagram that stiows fixed policy activation tokens according to the invention; 
Fig. 9 is an illustration of the principle of decoupling according to the invention; and 
35 Fig. 1 0 is a block diagram that shows da&s of service mapping according to the invention; 
Fig. 11 is an illustration of the COS kientifier name space according to the invention; 
Fig. 12 is a block diagram that shows a predefined dass of service identifiers according to tiie invention; 

40 

Fig. 1 3 is a btock diagram tiiat shows negotiated dass of service identiifiers according to ttie invention; 

Fig. 1 4 is a btock diagram that shows random class of service identifiers according to the invention; arxi 

45 Fig. 1 5 is a block diagram that shows variant and invariant class of service attributes according to the invention. 

[001 3] National cryptography policy often varies by industry segment, political climate, and/or message function: This 
makes it difficult to assign one uniform policy across all industries for all time. Consequentiy. the flexibility of a cryptog- 
raphy framework that incorporates a National Rag Card, a.k.a. a policy activation token (PAT) is very attractive. The 
50 invention is therefore directed to resolving problems surrounding international ayptography The invention preferably 
resides in an International Cryptography Framework (ICF) tiiat allows manufacturers to comply with varying national 
laws governing the distribution of cryptographic capabilities. In particular, such a framework makes it possible to ship 
wQrWwvde cryptographic capabilities in all types of information processing devices (e.g. printers, palmtops). 

55 ICF Elements 

[0014] The invention preferably resides in an international cryptography framework that has four service elements, 
each offering different types of services. Fig. 1 is a block diagram of the international cryptography framework (ICF), 
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including a Policy Activation Token 12, a Cryptographic Unit 14. a Host System 16. and a Network Security Server 18. 
Three of the four service elements have a fundamentally hierarchical relationshp. The Policy Activslion Token (PAT) is 
installed into the Cryptographic Unit (CU) which, in turn, is installed into a Host System (MS). The Host System runs an 
application 10 that may require cryptographic services. Cryptographic functions on the Host System cannot be exe-. 
cuted without a Cryptographic Unit, which itself requires the presence of a valid Policy Activation Token before if s serv- 
ices are available, e.g. to the application via the Host system. For purposes of the discussion herein, the Policy 
Activation Token is also referred to as the policy card because it provides the discipline that exerts a national cryptog- 
raphy policy. 

[001 5] The fourth service element, a Network Security Server (NSS), provides a range of different security services, 
including verification of the other three sen^ice elements, and thus acts as a trusted third party. Messages encrypted 
using the proposed framework carry an electronic stanp identifying the national cryptography policy under which the 
message was encrypted. TTie Network Security Server also provides stamp verification services for message handling 
systems. 

[0016] As discussed above, the four basic elements of the ICF architecture are the host system, the cryptographic 
unit, the policy activation token, and the network security server. For purposes of the discussion herein, these elements 
of the ICF are defined as follows: 

Host System fHS>. The HS is the system or unit that contains a Cryptographic Unrt (CU). This element of ICF sup- 
ports an Application Programming Interface t© a CU. It also supports applicatior© 10 that are security aware and 
that make use of the CU. These applications are bourd tightly to the CU during runtime. 

Cryptcxpraphic Unit fCUV The CU is ihe system or unit that contains th© cryptographic functions. These functions 
are dormant and cannot be used by the HS until activated by a PAT. The a>ptographic functions which are included 
in the CU are typically determined by business demand. The CU is tarr^er resistant so as to protect any keys that 
may be stored therein. It is the CU's responsibility to participate in all PAT maintenance activrties. Failing to do so. 
results in the CU*s functionality returning to the dormant state. 

Policy Activation Token (PAT>. The PAT is ths token contains cryptogr^h^' usage policy. Specificallv^ this ele- 
ment of the iCF contains parameters that govern the us© of cryptogrepiTiy sn a specif Ic CU. Policy activation tokens 
can be in phy^cal form, virtual form, and a fixed fcf m. Physical PATs bub physicaG tokens, such as a smart card, 
containing the cryptograf^ic usage poiicy: virtual PATs are software elemervts corrtainiBTg cryptographic usage pol- 
icy which can be sent over networks to the target CU; and fixed PATs are boiind to a single application arxl contain 
the cryptographic i^ge policy for those applications. 

Network Seciirrty Server fNSSV The NSS is the system or unit that acts as a trusted third party to provide net- 
worked services to HSs and CUs. These services include, for example, policy enhancements, unit verification, 
adjustments to authorizations, and key nnanagement sen^ices. 

[0017] As an element of the ICF architecture, the host system contains some unique characteristics. The invention 
herein focuses on these characteristics of the host system of the ICF. 

Operating System Support Elemems 

ICF Runtime Environment 

[0018] The ICF host system software architecture describes the layers of libraries and system elements which are 
needed to implement the ICF elements on a given host system. In general, there are three important layers, /.e. appli- 
cation, operating systems, and cryptographic sendee providers. Fig. 2 provides an overview of the main softwrare archi- 
tecture elements. 

Applications. The applicalon layer 20 is the area of user written applk:ations and libraries which need cryptographic 
sendees. An application may or may not be aware of these sen^lces. In case they are aware, the subsystem layer 
21 t>elow offers a set of programming interlaces to the application. Cryptographically unaware applications do not 
issue any calls themselves, the underiying sut>system performs these on behalf of the application. 

Subsystem Ubrarios and Interfaces 21. Subsystems which support cryptographic functions for aware and unaware 
applications. These siJasystents also provide APIs to the applications. Most notable APIs include the Miaosoft 
CAP! for f^icrosoft applications, and the X«pen GSS-API and GCS-API for Unix applications. Sii>system libraries 
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typically organize theTOeives into appiication programming interfaces and, shielded through the operating system, 
into a cryptographic service provider module. 

[0019] The subsystem libraries may also hide the security APIs completely from the applicatfon. ITiis allows existing 
5 applications to take advantage of the solution without being nrodified. An isxampie is ^he integration of security features 
into transport level software subsystems. 

[0020] Other elements of this layer may provide APIs for accessing the CU secure storage and execution facilities. 
For example, a database API such as the ODBC Interface could be offered along with a data manager module inside 
the CU to provide a tamper resistant database. 

Operating Systems and Drivers. The operating system 22 performs two primary tasks. One is to isolate the subsys- 
tem programming interfaces from the cryptographic service providers. The other task Is to provide the necessary 
hardware control through a set of drivers 23 which interlace with the cryptographic hardware in form of hardware 

drivers. 

Cryp to graphic Unit Subsystem 24. This layer contains the hardware implementation and firmware elements of the 
cryptographic functions. The hardware typically comes in several form factors, such a PCI card or a PCMCIA card, 
to accommodate the different hardware platforms and performance requirements. The firmware is a set of libraries 
v/hich implement a runtime (which is similar to a micro-kernel), the ICF functionality, and user downloadable soft- 
20 ware modules required by a particular application programming irrterface. 

Administration. The administration 25 element is responsible for providing a managanent framework for the entire 
solution. This includes, for exanple. middleware components for administrative functions, such as certificate man- 
agement, application class of service management, and downloading of a^Dlicatjon specific extensions to ^M) CU. 

25 - 

ICF l\/^naqemgnt Fr3fnewQrK 

[0021] Fig. 2 is a block diagram showing ICF management elements according to the Invention. Arcund the core eie- 
ments of the ICF are the manufacturers of the cryptographic equipment 30 and the domain siuthorities 32/34 which 
30 inplement the policy definition and enforcement through the framework. There are four t>asic elements within the 
administration framework. They are the Security Domain Authority 34. the Application Dorriain Authority 32, the Host 
System Elements 16. and the Network Security Server 18. 

Securitv Domain Authorrty. The security domain authority (SDA) is the institution which defines the security policies. 
35 Security policies are presented to the other framework element via classes of services. Knowledge of manufac- 
turing information allovs the system to create dasses of services targeted to a deterministic set of CUs. 

Application Domain Authority. The Application Domain Authority (ADA) acts as the authority to create certificates 
for the application. The certificate contains the granted classes of service to the application as they were granted 
40 by the SDA. 

Network Securitv Server. The Network Security Server (NSS) acts as the trusted on-line authority nnanaging the 
policy activatk>n for a given CU. 

45 Host System / Application / CU. The host system on which the applications are installed and the CU services are 
being used form the execution elements to be controlled by the framework. 

[0C22] The security domain authority (SDA) is responsible for granting a set of classy of service (COS) 35 to the 
application domain authority. The SDA is also responsitDie for issuing policy cards which oorrtain the COS information 
so and the Touch Point data for the CU. The SDA manufactures this information tpon request from the site which installs 
the CU into a host systerrr 

[0023] The application domain authority (ADA) r^eives the COS elements granted by the SDA. It has the responsi- 
bility to ^ue application certificates 36 to the applications t^ldnging to its domain. An application certHk^ate contains 
the application ID and the COS granted by the ADA. 
55 [0024] Applications receive a certificate from the ADA which they need to present to the CU to get the desired COS 
te^e!. The CU. upon receiving the request, uses the certificate to determine whether the application has the right to 
acG6;js the requested cryptographic function If the COS requested through the application certificate matches the COS 
granted by the SDA to the ADA and stored in the policy card then the request is handled. othenAfise it is not handled. 
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[0025] The network security server (NSS) 18 acts as an on-line instrument for policy negotiation and changes to the 
policy information stored on the policy card. If. for exarrpie. adding a class of service to the set of services normally 
requires the issuing of a new policy card with the changed information. Alternatively the NSS performs an update of the 
policy card on behalf of the SDA. The NSS also plays the role of activation system 37 for virtual policy cards. 

5 

Basic iCF Host System Assumptsons 

[0026] The ICF architecture rests on a few very basic assumptions about the core elements, as listed below. 

10 Certification. All software elements have a level of trust associated with them, whether they are firmware conpo- 
nents installed inside the CU or applications using the services exported by the CU. The methodology used to 
transfer trust in software throughout ICF is certification. All trusted operations, e.g. the downloading of firmware 
modules or an application for a certein level of service, involves the validation of the associated certificate. 

,5 ProvidinQ Cryp tmra phic Functions. The CU does not provide the HS with any cryptographic functions without 

being in possession of a PAT 

Separation. Under no circumstances can user date being processed within the CU be accessed by the policy ele- 
ments. regaixJIess of PAT format . Ukewise, under no circumstances should the host system have access to the pd- 
20 icy's Touch Point data information. 

Trust Relation between Applications and CU Services 

[0027] Applications are tiie requesting element in ICF Typicaliy. they run on a host system and request services from 

25 theCU. - ' 

[0028] An integral part of tiie ICF architecture is the bi-directional trust relation between the application requesting a 
service and the service provider delivering this service. As described in U.S. patent application serial nos. 08/748,085 
(Dynamic Qasses of Service for An International Framework); 08/770.747 (Software Level Touch Points for an Interna- 
tional Cryptography Ramework); 08/702.331 (Application Certification for an International Cryptography Framework); 

30 08/702.304 (Method and Apparatus for Enforcing the Use of Cryptography in an International Cryptography Frame- 
work); 08/702.332 (Method and Apparatus for Trusted Processing); and 08/685,076 (Cryptographic Unit Touch Point 
Logic), which patent applications are incorporated herein by this reference thereto, a system can be constructed con- 
sisting of an application and a cryptographic unit which assumes no other trusted elements tiian the CU and a frusted 
direct path to the application code image. The CU validates ttie identity of the application based on the code image 

35 before providing tiie desired service. 

[0029] Fig, 4 illustrates the trust relation between an application 10 and a CU 14. For systems which do not provide 
this type of access from the CU to the host system memory space, the challenge becomes to establish one or more 
mechanisms which sti^engthen the trust relation between the two communicating elements. There are two pnncqp)al 
strategies. One is to construct a line of trusted elements from the CU to tine application, tiie otiier approach is to guard 

40 the CU/application interaction with nrany validation checks, which varies attack detection time. 

[0030] One aspect of the inventfon constructs a line of trusted elements from the CU to the application. For example, 
with the CU at the bc«om of a chain of trusted elements, the CU is able to validate tiie OS drivers needed fbr passing 
a request to the CU. The valklated drivers can tiien implement trusted mechanisms to validate the driver calling mod- 
ules, which themselves can irrplement. for exanropie. validation schemes. Trust is extended towards ttie application. The 

45 assumption for the valkteitions of the OS driver. Le. the starting point of the chain of trust, is that tiiere is sufficient trust 
built into the access control and authorization mechanisnrrs of the Host system kernel. 

[0031] The invention inplements a series of validations and checks into the application/CU interaction. In ttiis 
approach, rather ttian constructing a line of frust from tiie CU towards the application, several mechanisms and valida- 
tion checks are in^tlemented into the interaction between ttie CU and the application. While each of these mechanisms 
so may not be powerful enough to withstand an attack, tiie combination of tiiese mechanisms may make it sufficiently dif- 
ficult for an attacker. 

[M32] The following descrit>es some of tiiese mechanisn^s: 

Strictiv monotoninailv increa^ nq gftqiience numbers. In this scheme both parties pass a Strictly monotonically 
55 increasing number atong with the request. If eitiier party detects an unexpected number, then a failure in the com- 
munication, possibly an attacK can be assumed. 

Pass challenge tnkpn<. along wi th the request. Both parties can pass a challenge back and forth which involves 
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computatidn on both skJes. The corrpjtation at each party relies on a previous value to detect sequence failures. 

Use timer approaches. If operations are known to be within a certain time boundary, this information could be used 
to detect anomalies in processing, potentially hinting at an attack. 

5 

Ask the application party to pass randomly selected pieces of the code ima ae to the CU party. In this scheme, the 
CU asks for a randomly selected memory portion of the application in an effort to ensure that a request cannot be 
issued by a malicious application. Because of the use of a chained hash scheme, such random selection of mem- 
ory portions makes it more difficult for an attacker to guess the memory location and more easy for the system to 
10 detect such intervention. 

[0033] All of these approaches have in common that they alone cannot guarantee the authenticity of the requesting 
applicatton. The underlying challenge to all of these approaches is the non-trusted environment in which one cannot 
perform safe storage or safe computation to identify a party in this environment. All of the proposed schemes have 
75 weaknesses which make them subject to attack. The cont)ination of the rather weak grourxi level schemes, however, 
proves to be very difficult to bypass without detection. 

[0034] All approaches for strengthening the trust relation between the application and the CU as described above suf- 
fer from the fact that ihe application requests the operation and tiie operation is carried out inside the trusted boundary 
of tlie CU. The application is free to obtain the service otherwise, thereby completely bypassing the CU. The CU itself 

20 has very limited means to validate the application identity and needs to rely on, for example, the host environment. 
[0035] A different split in responsibility between application and CU improves the situation considerably. If, for exam- 
ple, part of the application is executed inside the trust boundary of the CU. the application on the host system bocomes 
incomplete and replacing this application or complementing the missing pieces becomes more difficult. 
[0036] Larger blocks of application functionality inside the trust boundai y also irr^rove the situation by making the 

25 service exported from the CU more high level, thereby reducing the risk of misuse of lower functionality of the CU whicTi 
is not exported anyrnore. 

Application Support Elennents 

30 Application Authentication 

[0037] ICF applications can t>e certified. A certifk:ate contains identifying attributes of the application, e.g. the Appli- 
cation ID, the hash sum of the application code image, and tiie classes of service assigned to this application. This infor- 
mation is authenticated by means of a digital signature. The CU uses tiiis information to accurately identify an 

35 application and determine the kind of access which can be granted. 

[0038] The signature process, while straightforward, requires some administrative effort and a management infra- 
structure. Changing just one bit within the application code image, requires the system to go through tfie full process of 
producing the signature. Depending on the certification infrastructure, an application developer may need to submit its 
work to another entity to get it signed, which puts a serious constraint on the application distritxjtion. 

40 [0039] Replacing a version of an application by the next version requires a level of trust and control. The application 
authentication mechanism is used to validate the origin of an application before it is used. It is desirable for the target 
system to specify control optbns on the application update process. For exanple. a host system may deckde not to 
accept new versk}ns of a loaded application automatically 

[0040] Fig. 5 is a btock diagram thai shows an application installation and update according to the invention. Installing 
45 an application A* can be characterized by the dependency it has with respect to the previous application A. 

No Dependency. A* is not related to A. The signing identity may not be the same. This; is the most genera) case. 
Applications are referred to by the same name. Usually, tiie signing authority s^ys the same. 

50 Signature Dependency. A' is only accepted if the signing identity is the sanne as l>!at used in signing tiie module 
currentiy known. This is the most typical case. Applications are accepted ancA replace the previously installed appli- 
cation if the signature Identifies a trusted application producer. 

Backward Dependency. A' is only accepted if A* contains information about A and its signature. Direct backward 
55 dependency orriy acc^ts the immediate predecessor of A*, indirect backward dependency accepts any module in 
the chain of previous A. This scheme considerably strengtiiens tiie control a system has over installing applica- 
tions. 
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Fprward Dependency. An application may specify options which influence the acceptance of a successor version 
A*. 

Code Eqtiivgignce 

[0041] Code equivalence is the fundamental property the Host System maintains while changes to certified applica- 
tions are being loaded. The initial problem of code equivalence is bound to the known difficulty to demonstrate the cor- 
rectness and computability of the initial code. In the preferred embodiment of the invention, the two criteria are achieved 
with an appropriate cont>ination of development processes and procedures, as well as valictetion checkpoints. 
[0042] The following steps describe how the specific criteria are achieved. The proposed heuristic builds on three 
parts: 

. The executable components 50. represented by tiie shadowed rectangles in Fig. 6; 
75 • The Checkpdm conponents 51. represemed by the rounded rectangles in Fig. 6; a^ 
• The Transform component 52, represented by a simple rectangle in Fig. 6. 

[0043] For purposes of the discussion herein, there is no distinction in terminology between the code to be executed 
20 or the attached data structure when the word "component* is used. 

[0044] Before the components are described, it is necessary to introduce the state variable. The following descnbes 
how the state variable is used. A fully functional, well contained subsystem is either part of tiie whole system or is the 
whole system rtself and is characterized by a set of features. When the set of features is in the initial slate, it is referred 
to as the Base A Base in a grven state coukJ claim that the set of features f if tiie Base meets tiie correctness criteria. ^ 
When the Base is upgraded, it is in fact augmented with new features e.g. f 1 or state s. The upgrade means effectively - 
a change of state from s to s+1 . Hence, versions of the Base and the Edition are kept compatible because they refer to 
the same state. With this exanple in mind it is easy to introduce the two categories of executable components. 
[0045] The Executat)le Components. ^ ^. uu 

[0046] The first category of executable components is the Base and the second category is the Feature, which either 
replaces existing features of the Base or augments the Base with new features. A new addition to the Base creates the 
new Base. The new Base Is distinguished from tiie old Base by the change of value of the state variable, represented 
symbolically by s+1 . In Fig. 6. the change of state Is represented by the black arrow 53. As an illustration, tiie change 
of state goes through the following steps once the signature of the Base and new Compound Base is verified: 

1 . The transform hash refers to the chain of transform functions to be invoked to install tiie new feature In addition 
to tiie state s hash value. 

2. If the hash matches the hashed reference chain and the state s. the Feature f is correct and can be installed 

3. The feature is installed using the Transform chain, e.g. dynamic link. load, or resolve. 

4. The state of the new Base is updated to s+1 . 
The Checkpoint Components. 

[0047] The checkpoints are used to validate a stage in the process. The intermediate checkpoint, referred to as "Hash 
of the transformed f refers to tiie transfornr^tion of the feature f by the tiransfomi function T 

The Transform Component. 

[0048] A Base can only be executed once compiled, loaded, and linked with the libraries and the data structures. 
Once loaded the symbol resolution and the relocation has been solved, and tiie set of combined features is now the 
executable binary. The transform function represents all combined mechanisms involving the compiling, tiie loading and 
linking. A reference to hash of the chain of mechanisms is the reference transformation T 

Ap plication Lev^i Resource Mao 

[0049] Fig. 7 is a block diagram that shows downloading and execution of a software application module according to 
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the invention. Typical environments found in client server architectures construct a closed environnnent in which the 
application runs. An example of this strategy is the Java virtual machine environment 70. In this example, applications 
71 . referred to as applets, are downloaded to the client system. A signature validation process can be applied to the 
applet to verify that the applet has been signed by a trusted entity, such as the supplier of the applet. After some further 

5 integrity checks, the applet is allowed to run inside the environment of the virtual machine. 

[0050] Validating the authenticity and integrity of an applet is however only one aspect of the security requirements 
of the host system. Applets typically need to interact with the host system resources. This forces the system to provide 
gateways from the closed environment in which the applet executes to the host system resources. Current modeSs 
which provide an all or nothing strategy are not sufficient to satisfy the needs of the applet designer. 

10 [0051] The ICF architecture provides the concepts of a dass of service which can be seen as the trusted description 
of an applications resource map. COS identifiers label the resource. COS attributes express what an application is 
capable of with respect to the host system resource. Issued and signed by an ICF domain authority, the Resource Map 
COS cannot be manipulated to acquire access to resources beyond the application assigned capabilities. The CU as 
the enforcing element itself is a trusted location where the evaluation of the application resource requirements takes 

15 place. Elements of the ICF architecture such as application level touchpoints, described in U.S. patent no. 5,651,068, 
and the fact that a CU can execute application methods in a secured location, further strengthen the validation of the 
executing applet. 

Application Rxed Policy Activation Tokens 

20 

[0052] Application fixed policy activation tokens, referred to as fixed PATs, are tokens targeted at the activatkjn of a 
cryptographic unit for a particular application. This is different from the physical or virtual PATs, which are targeted at 
the activation of a particular cryptographic unit 

[0053] The motivation for fixed PATs is to provkle ia unit of distribution wliich inciLdes eirer ything from application tp 
25 the policy activation tokens necessary to enable the application to consume tfie cryptographic se? vices provide by a CU. 
[0054] rig. 8 is a block diagram that shows fixed policy actrvation tokens acooiding to ti^^e invention. In the example 
shown on Fig. 8: 

Applications 80 have a unique identification, e.g. a serial number. 

30 ' ' 

The COS constraint binds the application serial number to the COS. 
There is a COS test level for this case. 
35 A pplications and Passes of Services 

[0055] A class of service consists of a COS identifier, e.g. a number, and a desaiptive part which contains the iden- 
tifier of the associated method and constraints which must be evaluated before access to the method is granted. The 
desaiptive part is signed by an authority to assure its authenticity and integrity. 

40 [0056] COS identifiers can be distributed thrcHigh a different channel than the descriptive part. For example, in the 
case where the COS is associated with a cryptographic method, the COS identifier is passed to application domain 
authorities which, in turn, harxJ them out to applications which request service from the CU. The COS descriptive part. 
i.e. the part which provides the CU with the necessary content to evaluate requests can-ying the corresponding COS 
identifier, is distributed via the NSS infrastructure. In the case where the COS represents a non-cryptographic method. 

45 this separation may not be necessary. 

The Principle of Decoupling. 

[0057] The ICF architecture defines clear responsibilities of the element application, resources, and administrative 
so domain. Under ICF. applications request resources from the cryptographic unit using the Class of Service identifier, 
which labels the cryptographic attributes of the request, as the handle to that description. Basides cryptographic func- 
tions. other arbitrary operations can be labeled by this mechanism. 

[0058] Classes of service are. associated with ah application by the administrative functions of the framework. 
Although an application can issue a request using a different COS, it has no way of modifying or creating the attributes 
55 encapsulated in the COS. The CU itself provides mechanism to validate that the application is using a COS which was 
assigned to it by a recognized domain authority. 

[0Q59] Class of service attritxrtes, i.e. the content of the COS describing the operation to be can-ied out by the 
resburce, are determined and controlled by the adrninistrativs functions available to the domain authorities- There is no 
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path for the application developer to influence the content of a COS. This decoupling of administrative functions from 
application developer and application user is a key principle of the ICF architecture. Fig. 9 provides a graphic illistration 
of this principle. 

[0060] As applications are more and more handling enterprise critical data and consumer private data, the isolation 
5 of application creators from manipulating the underlying resources is becoming a key requirement. Tnis requirement 
which only existed in a few financial applications and pea-haps classified applications is now making inroads to other 
applications categories dealing with electronic commerce as well. 

PAT Support Elements 

10 

Class of Serv ice MapDino 

[00611 Applications communicate their requests to the cryptographic unit for execution. Each request has to contain 
information which allows the cryptographic unit to derive the class of service for this request. The ICF defines two major 
15 approaches to mapping the request to the COS ID: 

• Applications can pass the COS identification number along with the request. For example, the application certifi- 
cate issued for the application contains the authorized classes of service tdentrfiers. 

• T\^e application can issue the request. It is the responsibility of the CU to analyze the request attributes and to 
20 determine the closest class of service which satisfies the request. 

[0062] Fig. 10 is a bJock diagram that shows class of service n-apping according to tlie invention. Applications can 
either pass the class of service to the COS engine, or the attributes of the desired operation. For example, a crypto- 
graphic aeration could have attributes on algorithm type or key length. The mapping function 90 analyzes the request 
25 91 atti-ibutes and determines the COS which satisfias constraints described in the attribute list. The least capable COS - 
is selected. If no COS is suitable, either the request is rejected, or the r'^uesl atn ibutes are passed fbnA^ard to the net- 
work security server to selesit the appropriate COS. 

[0063] The same scheme of COS mapping could also be used to implement an authorization engine 92. In a typical 
authorization engine, the calSer passes a set of request attributes «i?hich arc compared to a set of privilege attributes 
30 following the authorization ru3e. If the r^ull is posittvs. the caller is allowed to go ahead, otherwise not. ITie fact that a 
mapping COS coukJ be found can be seen as positive authorization. 



Class Qi Serv ice IdentHiers 

35 [0064] COS identifiers can be grouped into several categories. They are labeSIed predefined COS identifiers, negoti- 
ated or assigned COS identifiers, and random COS identrtiers. All COS identifiers form a number space with ranges 
assigned to the different categories defined. Rg. 1 1 shows the COS identifiers name space and its relation to the SDA. 
ADA. and Applications. 



40 COS Identifiers Name Space. 



45 



so 



55 



[0065] Predefined COS identifiers. Rg. 1 2 is a block diagram that shews prolef ined class of service identifiers accord- 
ing to the inventfon. Predefined COS identifiers are unique across every SDA. They are reserved for the ICF infrastruc- 
ture classes of senrice needed to manage and control the ICF management operations. A predefined dass of service 
is always signed by the ICF domain autJ-iority and the identifier is passed separately from the descriptive part. 
[0066] Negotiated COS kJentif iers. Rg. 1 3 is a block diagram that shows negotiated class of service Wentif iers accord- 
ing to the invention. Negotiated identifiers are the resuH of an interaction betvireen the ADA 32 and the SDA 34. A typical 
exanple is the generation of a class of service identifier for a certain set of cryptographic operatfon ttie ADA wants to 
grant within its domain. An ADA asking for the authorization to use a class off sendee is returned a COS identifier for the 
desired COS. A COS does not necessarily have to be created upon receiving such a request. For example, an ADA 
coukJ browse a public dictionary containing all defined classes of service and request authorization for a suitable one. 
The returned COS identifier is unique to the ADA/SDA relationship established by tiiis request. 
[0067] Negotiated COS identifiers are always unique within a security authority domain. However, it is quite feasible 
for one or many SDAs to agree on a COS identifier which is tiie same across tiiese domains. In a sense it becomes a 
predefined COS identifier. However, the selection of ttie same COS Wentrtier is performed by agreement, not by defini- 
tion as is ttie case for predefined COS identifiers. 

[0068] Agreement between two or many domains couW also be achieved tiirough ttie concept of COS mapping, it is 
not a requirement of the ICF architecture to have ttie same COS identifier for ttie same COS description. Two descr<p. 
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tions, i.e. COS attributes and constraints, can be the same and still be represented by a different identifier, even within 
the same domain. 

[0069] Random COS Identifiers. Fig. 14 is a block diagram that shows random class of service identifiers according 
to tiie invention. Random COS identifiers extend the COS concept to accommodate an application's need to request a 
5 COS dynamically for an operation created ad hoc during application execution. 

[0070] Although an SDA and ADA can generate a random COS if needed, random COS identifiers are typically used 
by an application. Random COS identifiers have no meaning in another domain. 

[0071] Random COS identifiers add a new sense of privacy to the COS. They may be used to identify a COS repre- 
senting a method agreed on by two parties which does not necessarily have to be visible to everyone else. A random 
10 COS could be used to describe a one time operation, e.g. a financial transaction. They are created not through the 
ADA/SDA interaction, but tiirough an application/NSS interaction. ADAs or applications, given tiiey have a COS to cre- 
ate a random COS, can create them for a single ti-ansaction, e.^. a merchant server authorizing a credit card transac- 
tion. 

[0072] Random COS usage scenarios include: 

75 

Scenario 1 : A company may ship an application with some of the application code associated with a COS. This 
code is downloaded into the CU and executes within the perimeters of the CU. The COS, a random COS guarding 
the code, is created by the application manufacturer and can be seen as the authorization token for the execution 
o of the application. COS attributes, such as number of usage or expiration time, are used to buikj a payment infra- 
20 Structure. 



Scenario 2: Agent technologies create mobile units of code, agents, which are sent to a target system and execute 
their on their owners behalf. The\ challenge is for the recipient client system to establish isolation boundaries for 
the agent to execute in. Solutions proposed so far either proposed a sandbox mode!, which gives no access to ttie 
client system resources, no limitations which make the client system subject to all forms of attack, or a coarse 
grained set of access rules for the visiting agent. 

An agent accompanied by a COS provkJes a more robust mechanisms for describing tfie agent, its identity, and 
the constraints to place on the execution of tiie agerit. Through the COS signature structure, tiie identity of the 
agent can be determined reliably, tiie cor:straints are guaranteed to not have been tampered with. A CU. a tanper 
recistant place on the client system, reliably analyzes the COS att-ibutes and ti-iggers the execution of the agent. 

Scenario 3: Usage of random COS in Authorization Processors. An autix)rization processor typically implements a 
decision system which evaluates application request attributes, called transaction attributes, wrth a set of privilege 
attributes, according to a fixed rule describing the authorization. The challenge for such systems have always been 
to store the privilege atti-ibutes securely arKi to provkie a robust and tamper resistance evaluation environment for 
the authorization processor itself. Typical design inplemented a centralized authorization service to which dient 
system requesting an authorization establishes a secure channel and to which it sends the transaction attributes. 
The answer sent back is them used by the application. 

[0073] Random COS are a secure way to transmit a the privilege attributes to the client system and to place the 
autiiorization evaluation into the CU of the client system. The net result is a signifk:ant improvement In locality of the 
decision making, while sti!l keeping the necessary level of security. 

[0074] As the scenarios above show, random COS identifiers extend ttie ICF infrastructure in a powerful way in ttiat 
they allow to label operations and a^ociate attrbutes with them on an ad hoc basis. The evaluation and enforcement 
of the attritxjtes rests on the trust foundation estalDlished through the ayptographic unit and the ICF domain authorities. 

COS identifier comparison 

[0075] Table 1 below summarizes tiie different COS identifier types and their characteristics. 



Table 1 



COS Identifier Ty^s 




Fixed COS 


Negotiated COS 


Random COS 


Who defines? 


ICF 


ADA/SDA 




General Use 


ICF methods 


Cryptographic methods 


Other methods 



25 



30 
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Table 1 (continued) 



COS Identifier Types 




Fixed COS 


Negotiated COS 


Random COS 


Use for cryptographic methods 


Yes 


Yes 


No 


Use for other methods 


Yes 


Yes 


Yes 


Distribution of ID vs.. corrtent 


Always separate 


Separate for cryptographic methods, 
optionally separate for other methods 


Optionally separate 


Signed by 


SDA 


SDA 


CU/ADA/NSS 



Variant and invariant COS attritHrt es 



15 [0076] Fig. 1 5 is a l3lock diagram that shows variant and invariant dass of service attrtoijtes according to the invention. 
Class of services are defined and created by the security domain authority. A COS 1 90 consists of an identifier 1 91 and 
a set of attributes 1 92 which describe the operation represented by the COS and the constraints on that operation. The 
COS is signed by the security domain authority to prove its authenticity and to guarantee its integrity as it is passed 
through the ICF distritxjtion infrastructure. 

20 [0077] The receiver of the CCS, i.e. entities who are in charge to create PATs for a particular CU. may wish to add 
additional constraints for a given COS. The ICF defines a method which addresses this need. Variant COS attributes 
do not define the actual attritxrte value. Instead they define the valid range of the attribute which can be defined by other 
administrative elements of the framework. 

[0078] A COS may have an invariant 193 and a variant 194 section of COS attributes. The invariant section defines 
25 the COS attribute value which cannot be changed or ovenidden once the COS is creal«l and signed by the SDA. The ^ 
COS attribute variant section defines attributes which have a range of valid values defined for the attribute and an 
attribute value which is assigned by defautt. The nunijer and type of atlrtoutes is defined at creation time and cannot 
be changed at a later point of time. Attrilxjtes cannot be added or removed from a COS. invariant attributes cannot be 
made variant and vice versa. 

30 [0079] The range of attribute values for an variant attribute 195 can be expressed as a range or a set.of values. 
Numerical attributes, for example, may specify a range characterized by a lower and an upper numerical t>ound. Enu- 
meration attributes may explicitly specify the permissible values as a list of values. 

[0080] Although the invention is described herein with reference to the preferred embodiment, one skilled in the art 
will readily appreciate that other applications may be substituted for those set forth herein without departing from the 
35 scope of the present invention. Accordingly the invention should only be linrtited by the Claims included below. 

Claims 

1 . An apparatus for establishing a trust relation that provides one or more degrees of trust within one or more ^5pli- 
40 cations and/or ope^ating systems (10) by expanding a level of trust provided by elements of an international cryp- 
tography frameworK wherein said international cryptography framework comprises a ayptographic unit (14), said 
apparatus comprising: 

a host sys;tem (16). said host system provkjing an execution environment that supports execution of said one 
45 or more supplications or operating systems; and 

a cryptographic service provider (18) that provides access for said one or more applications or operating sys- 
tems to sakj cryptographic unit. 

2. The apparatus of Claim 1 , wherein saki trust relation is established by any of a line of trusted elements from sakj 
so cryptographic unit (14) to said one or nrxjre applications and'or operating systems (10); and 

a plurality of validation checks which guard interaction between saki one or. wore applications and/or operating 
systems (10) and said cryptographic unit (14) by provWing a combination of several schemes whk:h. while indi- 
vkiually are not robust, are in combination difficult to bypass without detection. 

55 

3. The apparatus of either of Claims 1 and 2. sakI validation checks comprising any of: 

a series of strictly monotonically increasing sequence numbers which are passed with each request for com- 
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munication between said one or more applications and/or operating systems and said cryptographic unit, 
wherein a failure in communication is assumed if either said one or rtiore applications and/or operating sys- 
tems or said cryptographic service provider detects an unexpected number; 

challenge tokens that are passed along with each request for communication between said one or more appli- 
5 cations and/or operating systems and said cryptographic service provider, wherein said challenge token 

requires computation by both said one or more applications andyor operating systems and said a yptographic 
service provider; and wherein said corrputation relies on a previous value to detect sequence failures; 
a timer which determines a preestabiished service time boundary to detect anomalies in processing or evertts; 
a mechanism in which said one or more applications and/or operating systems passes randomly selected 
10 pieces of a code image to said cryptographic service provider; 

a mechanism in which said cryptographic unit requests randomly selected pieces of a code inrrage to ensure 
that a request to said cryptographic service provider cannot be issued by a malicious application; and 
a mechanism in which said one or applications in said cryptographic unit f equest randomly selected pieces of 
a code image using a chained hash mechanism to render guessing by an attacker more difficult arri to render 
75 detection of said attack trivial. 

4. The apparatus of any of Claims 1 to 3. wherein part of saki one or more applications and/or operating systems is 
executed inside a trust boundary of said cryptographic unit 

20 5. The apparatus of any of Claims 1 to 4, wherein said one or more applications and/or operating systems is certified 
by a certificate (36) containing the identity of the one or more applications and/or operating systems and those 
classes of service assigned thereto, wherein said certificate is usi^ by said cryptographic unit to identify sa;d one 
or more applications and/or operating systems and determine the level of access to cryptographic sen^ices that can 
be granted thereto; and 

25 wherein said one or more applications and/or operating syststtrs identity is optionally airthenticated by a sig- 

nature over a hash sum of sajd one or more applications and/or cperatirjg systenrjs code inMige. 

6. The apparatus of any of Claims 1 to 5. wherein replacing a present version of said one or more applications and/or 
operating systems by a next version thereof requires an authentication mechanism for said cryptographic unit to 

30 validate the origin of said next version before it is used. 

7. The apparatus of any of Claims 1 to 6, further corriprising: 

a signature validation mechanism that is applied to a module to verify that said module has been signed by a 
35 ti-usted entity, wherein said nnoduie is allowed to run inside a prescribed environment of a virtual machine. 

8. The apparatus of any of Claims 1 to 7, further comprising: 

fixed policy activation tokens (37) which activate a cryptographic unit (14) for a particular application and/or 
40 Operating system; 

wherein said one or nwe applications and/or operating systenr« have a unique identifier; 
wherein a class of service constraint binds said unique tdentifier to said dass of service; and 
wherein a class of service comprises: 

45 a class of service identifier (35) and a descriptive part which contains an kJentifier of an associated method 

and constraints which must be evaluated before access to said method is granted. 

9. The apparatus of any of Claims 1 to 8. further comprising: 

50 an authorization engine in which a caller passes a set of request attributes which are compared to a set of priv- 

ilege attributes fblkwing an authorization rule, wherein said caller is alk>wed to go ahead if said result is posi- 
tive, otherwise not 

1 0. The apparatus of any of Claims 1 to 9, further conrprising: 

55 

one or more security domain authorities (34); 

one or more application domain authorities (32); and 

negotiated class of service identifiers which are the result of an interacEson between said application donnain 
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authority and said security domain authority. 
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